Implement SIAF fondations staging endpoint - #337

New API Entreprise endpoint GET /v3/ministere_interieur/siaf/fondations/
{siren_or_siret_or_rnf}, exposing foundations (FRUP, FE, FDD) data from
the Répertoire National des Fondations operated by the Ministère de
l'Intérieur through the SIAF hub.

The endpoint is scaffolded in "prochainement" mode: MakeRequest inherits
from MockedInteractor, so it only answers on staging (mocked payloads)
and raises EndpointNotYetImplemented in production. This lets consumers
discover the contract and integrate against staging while the real SIAF
integration (auth, quota, production data) is still being contractualized
with the provider — the deadline is a staging release, not a production
one.

The response objects mirror the categories of the MI data reference,
which lists, per field, the upstream technical name and whether it
is served today: identifiants + identite (category 1), activite (2),
dirigeants (3), liens_entre_organismes (4), situation_financiere (6),
dossiers (8), documents (9). Keeping the reference's own grouping means a
field added upstream lands in an obvious place instead of forcing a
reshuffle.

The call key accepts SIREN, SIRET or the RNF identifier. The RNF code is
the official foundation identifier, set by décret n° 2024-720 of 5 July
2024, and formatted {department}-{type}-{number}-{suffix} — e.g.
075-FDD-00422-08 — which is what RNFIdFormatValidator enforces (the
example "FE-09303920-393" found in the reference spreadsheet is not the
registry format). It is also the only reliable key: ~22% of foundations
have no SIRET, and the provider states the SIRET is not trustworthy in
the SIAF referential. SIREN/SIRET are still accepted because API
Entreprise consumers key on them; the hub exposes no by_siren/by_siret
route, so the resolution will go through its advanced_search route at
wiring time.

What the contract deliberately leaves out, and why:

- Category 8 beyond the two fields the foundation record carries
  (isAccountLate, accountDepositYears): JOAFE publication dates and
  parution/avis numbers, the list of filed dossiers and their type,
  statutory amendment and dissolution effective dates, deposit and
  decision dates. All of it lives behind a separate SIAF "dossiers"
  route. One API Entreprise call must stay one provider call — merging
  two upstream calls doubles the latency and the failure surface for
  data that is secondary to the identity use case.
- Address, identifier and name of the legal entities a director
  represents (legalEntity.address / publicId / name): the field comes
  back empty ({}) on the DEV sample, and the only documented occurrence
  has publicId, name and country at null. We do not publish a field we
  cannot show working; adding it once the referential feeds it is
  backward compatible.
- Every "Future démarche" field of the reference (accounting amounts,
  countries and amounts of foreign financing, details of public
  generosity campaigns, liquidator, consumable endowment): publishing
  them now would force a breaking change when the upstream schema
  materializes; adding them later is backward compatible. The fiche
  announces them as a roadmap so integrators know the contract grows.
- Technical hub noise (hub_timestamp, createdAt, updatedAt, prefixS3,
  checksum) and website, never filled on the sample.
- The justificatives themselves: only their metadata is exposed. The
  download is a binary served by a distinct SIAF route and deserves its
  own endpoint rather than being smuggled into this one.
- isPersonDataPrivate, the provider-side flag gating the diffusion of
  director data per requesting administration: it has no meaning until
  the real integration exists, and will have to be honoured then.

Three vocabulary decisions in the schema:

- documents[].type is a closed enum of the twelve types the reference
  lists (category 9 "Pièce jointe"), ordered from the most frequent
  (statuts, comptes, rapport d'activité, procès verbal, which account for
  nearly every file observed on the DEV sample) down to the
  administrative and judicial acts a foundation only ever gets in
  trouble. It is non-nullable: typeFile is a required string upstream
  (FileMetadataFondationResponse), and advertising null would invite
  consumers to write dead branches. The reference flags one label as
  being renamed ("acte d'autorisation ou acte de non opposition" →
  "décision de l'administration"); the current label is kept, renaming it
  before the provider ships the change would document a value SIAF does
  not send.
- etat is described in prose rather than enumerated. The reference
  (category 1, "Etat de la structure") spells the states in French
  sentence case — en activité, suspendu, transformé, fusionné, scindé,
  dissous, the transformé/fusionné/scindé trio being exactly what
  liens_entre_organismes then details — while the SIAF DEV environment
  answers "Active". Freezing an enum on either spelling would put a wrong
  closed list in the public contract and would make our own staging
  fixtures lie. The vocabulary is to be pinned with the provider when the
  real integration lands.
- date_cloture_exercice states its order explicitly ("mois/jour, format
  MM-DD"): the upstream value is month-first ("12-31"), and a title
  reading "jour/mois" would have an integrator parse it as the 12th of a
  31st month and either crash or silently swap the fields.

The RNF identifier is matched case-insensitively: the FRUP/FDD/FE
segment and the optional department letter (2A/2B) are fixed markers of
the identifier's grammar, not data, so 075-fdd-00422-08 designates the
same foundation as 075-FDD-00422-08 and must not be rejected as
malformed.

Documents referenced here lives within https://linear.app/pole-api/issue/API-7216

Three representative foundations, one per legal type, so integrators can
exercise the contract's edge cases on staging:
- FRUP with a SIRET, reachable by RNF id, SIREN and SIRET (real public
  identity, Maison de la Chimie, with fictional contact and directors);
- FDD without SIRET, reachable only by RNF id — the case of ~22% of the
  referential;
- FE with a due date, a director representing a legal entity, and
  overdue accounts.

The staging token must carry every scope declared in authorizations.yml
(enforced by mocks' acceptance spec), so it is regenerated to include
the new fondations scope.

The fiche carries an alert stating the API is only callable on staging:
the "Prochainement" swagger tag alone flags the endpoint as upcoming but
does not tell integrators they can already try it on the test
environment, which is the whole point of this release.

The data description announces the roadmap (financial statements
amounts, foreign financing details, liquidator…) so early adopters know
the contract will grow: these fields are declarative data the SIAF
referential does not collect yet.

The fiche is attributed to the existing 'mi' provider, like the RNA
ones: SIAF is a Ministère de l'Intérieur system, not a separate
organisation. A dedicated provider entry would need its own logo asset
(providers/api_entreprise/<uid>.png) — every page rendering the partners
section fails without it — and would only make sense the day SIAF staff
get their own provider space.

The release is also announced in config/changelogs.yml (required for
any catalogue change): the entry links the fiche through endpoint_path
and stresses that the API is only callable on staging for now, so
readers don't try it in production.

The fiche declares the 'fondations' entity rather than reusing
'associations': the two registries are distinct (RNF vs RNA) and the
catalogue filters on that facet, so classifying foundations as
associations would surface this endpoint under the wrong search. The
entity is new, hence its label and icon are added to the site locales —
an entity without a translation renders blank on the catalogue.

Output of siade/bin/generate_swagger.sh. The generated spec is what the
site and the SDK scaffolding read, so leaving it stale would keep
serving a contract that does not exist to every consumer.

The fondations curl sample targets the staging host, as for any
prochainement endpoint.

Ruby and Node api_entreprise clients gain
ministere_interieur.fondations(siren_or_siret_or_rnf), scaffolded from
the regenerated OpenAPI spec. Minor bump per SemVer: new endpoint, no
breaking change. The endpoint only answers on staging for now
(prochainement mode), which the changelogs state so SDK users don't
report production 501s as bugs.

The scope index is flat and shared by every API Entreprise endpoint, so a
bare `fondations` would collide with any future foundations-related dataset
coming from another provider. Suffixing with the provider and its
information system (MI / SIAF) keeps the scope unambiguous, consistent with
the endpoint's controller path, and readable in the token scope list shown
to integrators.

The staging token embeds every scope declared in authorizations.yml (checked
by mocks' acceptance spec), hence its regeneration.